昨天提到如果能將開發過程中的這些「流動」（Flow）現形，那溝通起來會更加順暢，那這所謂的開發流動是什麼？可以先將其認知為從需求從誕生、進入開發、最後釋出營運中間的過程，為了方便聚焦討論，我大致會將其分成了三個面相去探討：

1. 如公路——需求生命週期（Requirements Life Cycle）：從何處流到何處？
2. 如號誌——開發流程（Development Process )：怎麼流？
3. 如路況——流動順暢度（Flow Efficiency）：流速如何？

接下來內容，主要是對於如何使三個面向現形的實務經驗做分享，前面會講一些概念，理解這些實踐背後的考量，接著分享我用了實踐與背後的脈絡，最後透過螢幕截圖與錄影，演示我怎麼使用這些工具的。我會盡量多講一點我這邊情境的實例，少講一點大家可以透過書本或網路就知道的理論。

🔎 與其他領域的連結
在為了充實本文而進行研究時，突然發現我要講的內容其實與 DevOps 三步工作法的「暢流」原則很像，內容或許也會有些重疊，這倒也是個驚喜。
在準備本主題的研討會分享時，依據的更多是在敏捷開發的實務工作遇到問題時，一個個解題的經驗，在過程中嘗試歸納、匯總成一個系統。在系統化的過程中，主要是參照今年剛學習的 Kanban Method，在今天的發現後，我想我也會多參照 DevOps 這塊的資料，讓我的實務經驗可以有更有趣的連結。

🔎 暢流原則 (Principles of Flow）：
讓工作順暢地從開發移動至營運，最後交付到消費者手上

需求生命週期

需求生命週期，就是一個需求從有到結束的過程，涵蓋經歷哪些階段、有哪些人或群體進行處理、要符合什麼條件。有點像是河道一般，總有從不同的支流匯集，宛如需求匯集而來；也可能會流到不同下游分支去，有如需求的交付或捨棄。

從不同角色或層次來看，需求生命週期可能是延到更長，或是只是某個視角的一小段。比如說在 Scrum 的實踐裡，成熟度低的開發團隊，或許他們聚焦的需求生命週期只有 Sprint Backlog 的長度，只專注在從認領到交付的這個區段，甚至有些比較資淺的成員，視野裡只有 Scrum Board 有如 Task Level。但在較成熟的開發團隊，可能就會思考到已排序的待辦清單裡，往未來多看 3 - 5 個 Sprint 的長度，甚至到客戶使用後的體驗、市場給予的成效等等。

對我來說，在這個面向也包括了，對於領域知識的掌握度，就像是對這個路途或這個海域的熟悉度一樣。越了解這部分，也會越知道需求還會怎麼流過來，哪些該流去放逐之地，哪些該流向正途。

開發流程

開發流程，也就是我們開發期間——從接到需求到交付期間的程序、方式、互動等等。有點像是這條高速公路的規則，比如說交通號誌、幾條線道、車流控管等等，可以說是需求流動的方式與策略。

通常這一塊也會是我們平常會專注改善的地方。但是過去常遇到的困境可能在於，我們很努力改善這裡，但卻沒有方式可以度量有沒有變得更好，更多是仰賴開發上的體驗與感受，最後會導致 Sprint Retrospective 開始流於形式，難以聚焦在應該改善的方向上。

比較好的方式，就是透過第三個面向——流動順暢度的度量指標，去檢驗我們訂出來的改善方真否有用，以及還有哪個地方是我們該著手調整的。

流動順暢度

流動順暢度，也就是需求從接受到交付的過程中移動的流暢程度。可以比擬為高速公路上的路況，有在使用 Google Map 的讀者可以想像平時是怎麼判斷路程的順暢度呢？多數仰賴的是擁擠程度，是塞車、還是順暢，或者是導航預估的花費時間是否與平時路程花費的時間差不多，對吧！同理，開發流動的順暢度，可能可以透過以下指標去意識到狀態：

• 單位時間的完成量或件數
• 同一路段的需求數（擁擠程度）
• 流動所花的時間（路程時間）
• 停滯的時間（大型停車場時間）
• 流動效率（停駛比， 有在流動的時間 / (有在流動的時間 + 停滯的時間) ）

流動順暢度會影響了需求給予客戶的交付時間，這也就代表著開發團隊是否能更彈性面對市場或需求變化的能力。通常平均交付時間越短，我們就越能因應需求去變化，這也就是我們常談到的敏捷性，對吧！

想想看，如果高速公路一直塞車，原本只要 20 分鐘的路程，卻得要將近 60 分鐘才抵達，這種速度是能接受的嗎？或者是，當道路塞到連路肩都滿了，如果突然有一個救護車要運行，是不是就沒辦法快速抵達目的地了？

綜觀開發流動的系統

那我們平時看這個開發團隊的開發流動好與不好，會從哪個角度切入呢？

如果是高速公路，是去看他的路段長不長嗎？還是看他上面的規畫與措施完整不完整？還是非常單純的看我行駛起來的順暢度與使用時間？我想顯而易見的是順暢度，對吧？

這邊或許會有人問說，看他上面規劃與措施完整度，也是一個指標？是也不是，或更危演聳聽一點，這樣做很危險。假設我今天一律以高速公路的規格套用在所有公路上，表面上所有公路都有最高規格了，應該每個地方都要跑還是要看各條公路的需求，不然只會是過剩的機制甚至干擾。

回到團隊上其實也是一樣的道理，我要判斷現在這個團隊的開發流動是否處於健康、預期的狀態，我看的就是開發的流暢度，然後再依此判斷我們是不是要去調整開發流程，以及用這個團隊所接觸的需求生命週期的區段作為邊界。

通常要去讓開發流動更順暢，應該是要這三個面向一起去探究，需求生命週期作為邊界與背景知識；開發流程則是運作方式，作為下手處；流動順暢度代表現況，作為衡量方式。

這就是我自己會用來檢視開發流動的一些觀念與結構。有了這些比較形象的概念後，我們來透過案例分享來探討怎麼一一現形這些流動吧！